Мы часто пишем об облачной платформе VMware vCloud on AWS (VMConAWS), которая позволяет разместить виртуальные машины на базе VMware vSphere в облаке Amazon AWS, а также построить гибридную среду, сочетающую в себе онпремизные и облачные ресурсы виртуальной инфраструктуры.

Сегодня мы поговорим об основном инструменте VMC, который позволяет управлять гибридной облачной средой. Сначала отметим, что управление такой структурой основывается на механизме Linked Mode, который объединяет серверы vCenter и позволяет использовать единое пространство объектов в географически распределенных датацентрах. Сейчас он называется Enhanced Linked Mode или Embedded Linked Mode (когда Platform Services Controller и vCenter Server Appliance находятся вместе на одном сервере).

Если вы разворачиваете Linked Mode на собственной инфраструктуре, то все серверы vCenter должны быть в одном домене SSO и иметь одну и ту же версию (включая номер билда). Когда же вы используете общий режим vCenter в гибридной среде (Hybrid Linked Mode), то ситуация, когда в облаке развернута более новая версия vCenter, считается нормальной.

Есть 2 способа использовать гибридный режим управления vCenter. Первый - это развернуть виртуальный модуль (virtual appliance) Cloud Gateway в своей инфраструктуре и соединить его с облачной инфраструктурой SDDC. Второй - это зайти с помощью vSphere Client на облачный SDDC и управлять объединенными ресурсами частного и публичного облака оттуда.

Во втором случае вы можете подключить только один домен онпремизной инфраструктуры, поэтому если у вас сложная доменная инфраструктура, то необходимо использовать первый метод.

Чтобы начать работу по созданию единой управляющей среды гибридного облака, нужно скачать установщик Cloud Gateway installer. Для этого надо зайти в консоль VMware Cloud on AWS и перейти на вкладку Tools. Там можно скачать этот виртуальный модуль:

Скачиваем ISO-образ Cloud Gateway и монтируем его к вашей рабочей станции. Запускаем его из папки /ui-installer и проходим по шагам мастера. На одном из них задаем параметры сервера онпремизного vCenter, где будет установлен шлюз:

В процессе установки вас попросят указать пароль root, целевой датастор, конфигурацию сети, NTP и SSO, также будет возможность присоединить шлюз к домену Active Directory.

Далее нужно переходить ко второму этапу - настройке гибридного режима Hybrid Linked Mode. Не забудьте свериться с требованиями к этому режиму в документации.

Далее нужно будет указать IP-адрес облачного сервера vCenter и параметры учетной записи cloudadmin@vmc.local.

Эту информацию можно получить в консоли VMware Cloud on AWS, выбрав ваш SDDC, затем Settings и развернуть поле Default vCenter User Account:

В качестве Identity Source нужно указать ваш онпремизный домен AD, для которого вы хотите настроить доступ.

После этого все будет настроено, и вы можете начинать управлять своей гибридной инфраструктурой через vSphere Client:

Многи администраторы VMware vSphere, особенно в крупных инфраструктурах, развертывают механизм VMware vCenter HA, обеспечивающий отказоустойчивость сервера VMware vCenter (а точнее виртуальной машины vCenter или vCenter Server Appliance, vCSA). Все понимают, что vCenter / vCSA - это важнейшая часть виртуальной инфраструктуры, ведь без нее не работают такие критичные сервисы, как Site Recovery Manager, NSX и Horizon View.

Функции vCenter HA появились еще в VMware vSphere 6.5, но в vSphere 6.7 Update 1 они были существенно доработаны, а сам процесс обновления и апгрейдов vCenter упрощен. При этом управление механизмом vCenter HA полностью перешло в vSphere Client в рамках единого рабочего процесса (раньше были 2 воркфлоу - Basic и Advanced).

Давайте посмотрим, какие пути апгрейда и обновления существуют для конфигурации vCenter HA. Для начала напомним, как это выглядит:

Две машины с vCenter (активный узел и его клон - пассивный узел), а также компонент Witness образуют собой кластер, где Witness защищает от сценария Split Brain в среде vCenter HA (не путайте это с обычным vSphere HA). В случае отказа основного узла, его функции берет на себя резервный, что существенно быстрее по сравнению с восстановлением vCenter средствами стандартного HA (перезапуск на другом сервере). Это в итоге отражается на меньшем времени RTO для таких критичных сервисов, как SRM и NSX, в случае сбоев.

Перед обновлением помните, что для vCenter HA не поддерживается создание снапшотов, а значит нужно обязательно сделать File-Based Backup основного сервера vCenter перед обновлением.

Если у вас VMware vSphere 6.5, то при обновлении вы можете не разбивать кластер vCenter HA, а просто скачать ISO-образ с обновлениями (через VMware Patch Portal), либо ничего не скачивать и сразу инициировать процесс обновления из командной строки, если у вас есть доступ в интернет из компонентов кластера.

Делается все это так:

• Сначала кластер vCenter HA надо перевести в режим обслуживания (maintenance mode), что не прервет репликацию, но предотвратит автоматический запуск процесса восстановления (failover).

• Затем заходим на компонент Witness по SSH и запускаем его обновление из командной строки. Если у вас есть доступ в интернет на этом экземпляре vCenter, то делается это простой командой:

software-packages install --url --acceptEulas

Если же вы скачали ISO-образ с обновлениями, то делается это следующей командой:

software-packages install --iso --acceptEulas

• Далее заходим на пассивный узел vCenter и там делаем то же самое.
• Инициируем вручную процесс восстановления vCenter на пассивный узел (failover).
• Обновляем активный узел vCenter.
• Возвращаем конфигурацию в исходное состояние (failback).
• Отключаем режим обслуживания (maintenance mode).

Если же у вас vCenter 6.7, то опция обновления у вас одна - отключение и удаление конфигурации HA, после чего происходит накат обновления на активном узле и повторное развертывание HA-конфигурации (такая же опция доступна и для vCenter 6.5). Этот рабочий процесс обусловлен изменениями в схеме базы данных, которые происходят в vCenter 6.7.

Начиная с vSphere 6.7 Update 1, установщик vCenter Server Upgrade installer может автоматически обнаружить присутствие кластера vCenter HA:

Далее в процессе обновления он сохранит его конфигурацию, обновит активный узел vCenter, а потом развернет его реплики для пассивного узла и узла Witness.

Надо понимать, что в процессе обновления машины с пассивным узлом и Witness будут удалены, поэтому не забудьте сделать бэкап. И сам процесс лучше проводить в ручном режиме, а не автоматическом, чтобы иметь больший контроль над получающейся итоговой конфигурацией.

Некоторые пользователи сталкиваются с проблемой при обновлении сервера VMware vCenter Server Appliance (vCSA). После накатывания апдейта на vCSA (в частности, здесь пишут про билд 6.5.0.30100) администратор идет по адресу:

https://<vCenter_FQDN>:5480

И видит, что страница не открывается, браузер не находит веб-сервер.

Это происходит потому, что иногда после обновления vCSA не поднимается служба vami-lighttp, которая отвечает за веб-интерфейс VAMI (Virtual Appliance Management Infrastructure). Нужно пойти в консоль vCSA и там выполнить следующую команду для вывода статуса этой службы:

ps -ef | grep vami-lighttp

Если вы увидите, что данный процесс лежит, то есть его нет в списке запущенных, то можно запустить его следующей командой:

/etc/init.d/vami-lighttp start

После этого VAMI должен начать работать. Также у vCSA есть загадочная зависимость от протокола IPv6, которая описана здесь.

Ну и посмотрите нашу статью, в которой описывается ситуация, когда страница VAMI на vCSA открывается, но при вводе учетных данных выводится сообщение "Unable to login".

Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.

Для тех, кто столкнулся с такой проблемой, Robert Szymczak написал полезный пост о том, как это сделать (но помните, что это неофициальная и неподдерживаемая процедура).

Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

\vcsa-ui-installer\win32\resources\app\resources\layout.json

Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
    }

Таким образом вы поймете, на какие именно конфигурации нужно изменить компоненты виртуальной машины с vCenter. Перед изменением конфигурации сделайте снапшот машины vCSA, который сохранит параметры ее виртуального аппаратного обеспечения.

Теперь переходим, собственно, к изменению самой конфигурации:

1. Увеличение CPU и памяти (RAM).

• Остановите машину.
• Хорошая идея - вывести ее ESXi-хост из кластера DRS.
• Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

2. Увеличение диска ВМ с сервером vCSA.

• Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
• Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

Примерно так это выглядит для vCenter 6.7 Update 2:

Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.

Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.

Если еще в Update 1 при установке нового плагина или обновлении старого, в случае неудачи процесс просто завершался, и приходилось смотреть в файл журнала, то теперь для этого есть графическое представление с выводом информации о возникших проблемах (например, несовместимость с новой версией платформы).

В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.

Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):

В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:

• Панель Recent Tasks в нижней части клиента
• Консоль в разделе задач (Task Console)
• Просмотр представления Tasks для выбранного объекта vCenter Server

Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.

Как происходит работа с плагинами

При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.

Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.

Ошибки плагинов при развертывании теперь детально описаны в консоли:

Также иногда к ошибке прилагается лог развертывания, например, в случае, когда их вызвало стороннее программное обеспечение, отдающее некоторый лог ошибки.

В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.

Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.

В этом случае vSphere Client обрабатывает плагины двумя способами:

• Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
• Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.

Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:

In progress

Плагин находится в стадии развертывания.

Deployed

Плагин установлен и доступен для использования через интерфейс vSphere Client.

Failed

Показывается при невозможности скачать или установить плагин:

• Download error
  • Установка из незащищенного места - используется http вместо https.
  • Невозможно получить URL плагина.
  • vSphere Client не авторизован для скачивания плагина.
• Packaging error
  • Поврежден zip-пакет плагина.
  • Отсутствует файл манифеста.
  • Отсутствует папка plugins.
  • Отсутствуют необходимые бандлы в плагине.
• Deployment error
  • Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
  • Собственная ошибка плагина (Runtime plug-in error).

Показывается когда плагин не поддерживается для данной версии vSphere Client. Возможные причины:

• Плагин добавлен в черный список администратором.
• В плагине прописано, что он поддерживает только конкретные версии vSphere Client (и вашей в списке нет).
• Это плагин на базе флэш-интерфейса под старый клиент vSphere Web Client.

На днях компания VMware выпустила третий пакет обновления для предыдущего поколения своей главной платформы виртуализации - VMware vSphere 6.5 Update 3. Напомним, что Update 2 вышел в мае прошлого года, так что давно было уже пора выпускать апдейт, так как версия 6.5 по-прежнему широко используется, особенно в крупных предприятиях.

Давайте посмотрим, что нового в vSphere 6.5 U3.

Новые функции vCenter 6.5 Update 3:

• События о добавлении, удалении и модификации пользовательских ролей содержат информацию о пользователе, который производит изменения.
• Улучшения возможностей аудита в компоненте VMware vCenter Single Sign-On - теперь появились события для следующих операций: управление пользователями, логин, создание групп, изменение источника идентификации, управление политиками. Доступна эта фича только для виртуального модуля vCSA с интегрированным Platform Services Controller. Поддерживаемые источники идентификации: vsphere.local, Integrated Windows Authentication (IWA) и Active Directory over LDAP.
• Поддержка новых внешних баз данных - добавлена поддержка Microsoft SQL Server 2014 SP3.
• Обновления ОС Photon для vCSA.

Release Notes для vCenter 6.5 U3 находятся здесь.

Новые функции ESXi 6.5 Update 3:

• Драйвер ixgben добавляет функцию queue pairing для оптимизации эффективности CPU.
• С помощью ESXi 6.5 Update 3 вы можете отслеживать использование лицензий и обновлять топологию коммутаторов. Также улучшения можно увидеть в Developer Center клиента vSphere Client.
• Поддержка устаревших серверов AMD Zen 2.
• Множество обновлений драйверов устройств: lsi-msgpt2, lsi-msgpt35, lsi-mr3, lpfc/brcmfcoe, qlnativefc, smartpqi, nvme, nenic, ixgben, i40en и bnxtnet.
• Поддержка Windows Server Failover Clustering и Windows Server 2019.
• Добавлено свойство com.vmware.etherswitch.ipfixbehavior в распределенные виртуальные коммутаторы, чтобы позволить пользователям выбирать способ трекинга входящего и исходящего трафика. Значение 1 включает сэмплирование для входящего и исходящего трафика, значение 0 включает его только для исходящего (значение по умолчанию).

Release Notes для ESXi 6.5 U3 находятся здесь.

Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.

Какие еще продукты VMware были обновлены параллельно с этим релизом:

• vSphere Replication 6.5.1.4 - просто обновление с исправлением ошибок.
• App Volumes 2.17 - поддержка Windows 10 1903, коммуникация с SQL Server по протоколу TLS 1.2. Остальное - здесь.
• User Environment Manager 9.8.0 - это большое обновление, подробнее о нем вот тут.

Некоторые пользователи, особенно после апгрейда сервера VMware vCenter Server Appliance 6.5 на версию 6.7, получают вот такое сообщение при попытке входа через интерфейс VAMI (Virtual Appliance Management Infrastructure):

Напомним, что интерфейс VAMI для управления виртуальным модулем vCSA доступен по ссылке:

https://<vCenter_FQDN>:5480

Причин проблемы может быть 2:

1. Пароль пользователя root устарел (кстати, помните, что в пароле нельзя использовать двоеточие). Для этого надо зайти в консоль vCSA и проверить это командой:

chage -l root

2. Не поднялась служба VMware Appliance Management Service.

Эта служба также кратко называется "applmgmt". Чтобы запустить ее через vSphere Client, зайдите в administrator@vsphere.local > Administration > Deployment > System Configuration > Services, выделите Appliance Management Service и нажмите Start.

Также можно сделать это из командной строки шелла vCSA:

service-control --start applmgmt

Далее нужно проверить, что служба действительно запустилась:

service-control --Status

Можно также поднять все сервисы vCSA одной командой:

service-control --start --all

Кстати, иногда после апгрейда хостов ESXi 6.5 на версию 6.7 внешний сервер Syslog может перестать принимать логи от vCSA из-за того, что правило фаервола ESXi для Syslog почему-то перестает быть активным. Можно снова включить это правило через интерфейс vSphere Client, либо вот такой командой PowerCLI:

Get-VMHost | Get-VMHostFirewallException | where {$_.Name.StartsWith(‘syslog’)} | Set-VMHostFirewallException -Enabled $true

На VMware Labs еще одно обновление - инженеры VMware выпустили продукт Flowgate, который представляет собой средство агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations).

В данном решении есть встроенный адаптер для интеграции со следующими системами DCIM и CMDB, которые хранят данные о составе, размещении и конфигурации ИТ-инфраструктуры:

• Nlyte
• PowerIQ
• Infoblox
• Labsdb
• IBIS (еще не полностью)
• Pulse IoT Center (еще не полностью)

С точки зрения интеграции с этими системами, все происходит в графическом интерфейсе в несколько кликов. Также внутри Flowgate есть встроенный механизм управления пользователями и ролями RBAC (Role Based Access Control) с большим выбором привилегий для конфигурации.

Надо отметить, что архитектура Flowgate открыта для интеграции с любыми другими сторонними системами. С помощью RESTFul API можно запрашивать любые данные и далее визуализовывать их уже как угодно, также все задачи управления решением доступны через API.

С точки зрения систем управления задачами ИТ-инфраструктуры, где собранные метрики визуализируются, на данный момент реализована интеграция с vCenter Server и vRealise Operation Manager, но скоро будет добавлена поддержка и других систем.

Более подробно о том, как работает Flowgate, можно узнать из следующего видео, созданного авторами Flowgate:

Для машины с Flowgate на борту, осуществляющей агрегацию данных, потребуется минимум 4 vCPU, 8 ГБ памяти и 60 ГБ диска, но рекомендуется выделить 8 vCPU и 16 ГБ RAM соответственно.

Скачать Flowgate можно по этой ссылке.

Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.

Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):

Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):

Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:

В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).

Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:

Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.

Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.

Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.

Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.

Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.

Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).

Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.

Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как  Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.

Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:

Недавно мы писали о том, как настроить сетевое соединение между Compute Network и SDDC Management Network в публичном облаке VMware vCloud on AWS (VMConAWS). Сегодня мы расскажем еще об одной полезности, предложенной Вильямом Ламмом - развертывании виртуального модуля VMware vCenter Server Appliance (VCSA) в такой инфраструктуре.

Начать надо с того, что когда вы запустите графический установщик виртуального модуля vCSA в среде VMC, то получите вот такое сообщение об ошибке на этапе указания параметров хоста для развертывания:

User has no administrative privileges

Это интересно тем, что на самом деле установщик vCSA не требует административных привилегий и, по идее, не должен выдавать такого сообщения об ошибке. Поэтому Вильям нашел, все-таки, способ развернуть vCSA в публичном облаке.

Для этого надо сделать следующее:

1. Создать вспомогательную ВМ (например, с Windows 10 на борту), которая будет использовать для развертывания нового экземпляра vCSA с помощью командной строки. Вы можете использовать для этой цели любую ОС, которая поддерживает интерфейс vCSA CLI.

2. Настроить соединение между сетевыми экранами Management (MGW) и Compute (CGW) для этой машины, как мы писали вот тут, чтобы установщик имел доступ к административной сети. 

3. Развернуть vCSA через CLI с помощью файла конфигурации развертывания в формате JSON, настроенного под ваше окружение. Вот пример содержимого такого файла, который вы можете взять за основу:

{
    "new_vcsa": {
        "vc": {

            "hostname": "vcenter.sddc-a-b-c-d.vmwarevmc.com",
            "username": "cloudadmin@vmc.local",
            "password": "FILLMEIN",
            "deployment_network": "sddc-cgw-network-1",
            "datacenter": [
                "SDDC-Datacenter"
            ],
            "datastore": "WorkloadDatastore",
            "target": [
                "Cluster-1",
                "Resources",
                "Compute-ResourcePool"
            ]
        },
        "appliance": {
            "thin_disk_mode": true,
            "deployment_option": "tiny",
            "name": "VCSA-67u2"
        },
        "network": {
            "ip_family": "ipv4",
            "mode": "dhcp"
        },
        "os": {
            "password": "VMware1!",
            "time_tools_sync": true,
            "ssh_enable": true
        },
        "sso": {
            "password": "VMware1!",
            "domain_name": "vsphere.local"
        }
    },
    "ceip": {
        "settings": {
            "ceip_enabled": false
        }
    }
}

После этой процедуры вы получите работающий VMware vCenter Server Appliance 6.7 Update 2 в своей инфраструктуре, который сможете использовать как для тестирования его возможностей, так и для полноценного управления виртуальной средой:

Недавно компания VMware выпустила новую версию платформы виртуализации VMware vSphere 6.7 Update 2. Довольно много новых возможностей появилось в функциональности управляющего сервера VMware vCenter 6.7 Update 2. Давайте посмотрим, что именно с картинками и анимированными гифками:

На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.

Давайте посмотрим, что с тех появилось нового:

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

• Доступно только для vSphere ROBO Enterprise.
• Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
• Применяются обычные требования vMotion.
• Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

• Шифрование домашней директории и файлов VMDK.
• Требуется инфраструктура KMS.
• Полностью безразлично к гостевой ОС.
• Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

Она дает следующие возможности:

• Конвертация топологии external PSC в Embedded через GUI.
• Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

• Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
• Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
• В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

• Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
• Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

• Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
• Новые категории теперь включают в себя:
  • Online Availability
  • Compute
  • Network
  • Storage
• Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

• Функции синхронизации шаблонов VM Template (VMTX).
• Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

• В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
• Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.

• Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
• Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
• Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

• Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
• Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

10. Улучшения безопасности.

• Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
• Можно применять лимиты для Password History и Reuse.
• Теперь логируются дополнительные события SSO.
• Улучшения ESXi certification API.
• Генерация запроса vCenter Server CSR доступна через GUI клиента.
• vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
• Доступна сертификация NIAP.

11. Улучшения производительности.

• Поддержка 40 & 100Gb Ethernet и RDMA
• Новая версия Virtual Hardware 15 (VM Compatibility):
  • До 256 vCPU на виртуальную машину
  • До 6 ТБ RAM на ВМ
  • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.

Одна из новых возможностей, анонсированных в платформе виртуализации VMware vSphere 6.7 - это vSphere Health. О ней мы уже вкратце упоминали вот тут.

Сегодня мы дополним эту информацию. Механизм vSphere Health опирается на глобальную базу знаний VMware, которая позволяет ежедневно выдавать предупреждения о 100 тысячах потенциальных проблем в инфраструктурах заказчиков и решать около 1000 актуальных проблем каждый день.

На данных момент vSphere Health включает в себя около 30 проверок (Heath Checks), которые запускаются для окружения vSphere. Вот примеры проблем, которые могут подсвечивать данные проверки:

• Утечка памяти в драйвере bnx2x
• Хост ESXi, использующий Intel Controller X710 для сетевого адаптера 10GbE SFP+ вываливается в "розовый экран" (PSOD).
• Ошибка L1 Terminal Fault (L1TF – VMM) - уязвимость типа Speculative-Execution в процессорах Intel.
• Хост ESXi 6.5 вываливается в PSOD при отключенном IPV6.

Для фиксирования, аналитики и поиска решений подобных проблем компания VMware использует облако VMware Analytics Cloud (VAC), которое принимает данные телеметрии виртуальных инфраструктур (онпремизных и SaaS-приложений) и формирует рекомендации по решению проблем. Сами данные в обезличенном виде передаются с помощью движка Customer Experience Improvement Program (CEIP).

Облако VAC постоянно анализирует пользовательские виртуальные среды, при этом оно постоянно пополняется новыми знаниями о проблемах, которые в асинхронном режиме отображаются в интерфейсе пользователей в vSphere Client (для vSphere 6.7 и более поздних версий).

Данные инфраструктур заказчиков, которые попадают в облако VAC через механизм CEIP, надежно защищаются. Их использование людьми доступно только для выполнения определенных задач. Сами правила регулируются комитетом Product Analytics Data Governance Board, куда входят инженеры, юристы, специалисты по безопасности и прочие сотрудники с различными ролями. Эта команда регулярно проверяет рабочий процесс использования этих данных. Естественно, эти данные не передаются третьим сторонам.

О том, какие именно данные собираются с помощью CEIP, и как они используются, можно почитать в специальном документе (он небольшой, 10 страниц). Включить CEIP можно через интерфейс vSphere Client следующим образом:

Также этот механизм можно включить при апгрейде платформы vSphere или через интерфейс командной строки (CLI). В рамках CEIP собирается следующая информация о виртуальной среде:

• Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
• Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
• Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и чсиленных значений (отклик интерфейса, детали об API-вызовах и прочее).

Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP (например, Skyline), то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.

Чтобы посмотреть текущие проверки Health Checks, нужно перейти на вкладку Monitor сервера vCenter Server, после чего перейти в раздел Health:

Там видны проблемы и объекты, к которым они относятся (в данном случае, к хостам ESXi):

Завтра мы расскажем подробнее о том, как работают эти проверки, какие решения они предлагают, и как помогают администратору держать виртуальную инфраструктуру в порядке.

В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:

Больше пяти лет назад мы писали про проект vCenter Server Simulator 2.0 (VCSIM), который позволял протестировать основные интерфейсы VMware vCenter без необходимости его реального развертывания (а значит и без лицензии). Проблема в том, что он был выпущен для VMware vSphere и vCenter версий 5.5 и с тех пор не обновлялся.

Зато есть аналог старому VCSIM - новый проект govcsim, написанный на языке Go (Golang). Он точно так же умеет предоставлять API-ответы на вызовы к vCenter Server и ESXi.

Несмотря на то, что этот симулятор написан на Go, он позволяет вам работать с vCenter посредством любого языка и интерфейса, умеющего общаться через API (в том числе, PowerShell). То есть, вы можете соединиться через PowerCLI к VCSIM Docker Container и работать с ним как с сервером vCenter.

Сам контейнер nimmis/vcsim можно скачать отсюда. Pull-команда для него:

docker pull nimmis/vcsim

Далее можно выполнить вот такой сценарий (взято у Brian Bunke):

docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest

If ($IsMacOS -or $IsLinux) {

$Server = 'localhost'

} Else {

$Server = (Get-NetIPAddress -InterfaceAlias *docker* -AddressFamily IPv4).IPAddress

}
If ($PSVersionTable.PSVersion.Major -ge 6) {

Test-Connection $Server -TCPPort 443

}
Connect-VIServer -Server $Server -Port 443 -User u -Password p

# Did it work?

Get-VM

# Or Get-VMHost, or Get-Datastore, etc.

Этот код делает следующее:

• Запускает docker-контейнер VCSIM локально (если у вас его нет, то он будет загружен).
• На Windows-системе получает IP-адрес адаптера DockerNAT.
• После запуска контейнера тестирует, что порт 443 отвечает.
• Использует модуль VMware.PowerCLI интерфейса PowerShell для соединения с vCenter Simulator.

Симулятор на данный момент поддерживает не все множество API-методов (смотрите документацию). Вот так, например, можно вывести список всех поддерживаемых методов и типов:

$About = Invoke-RestMethod -Uri "https://$($Server):443/about" -Method Get

$About.Methods

$About.Types

Например, вы можете использовать PowerOffVM_Task, PowerOnMultiVM_Task и PowerOnVM_Task. Из PowerCLI попробуйте также протестировать командлеты Stop-VM и Start-VM. Ну а дальше изучайте документацию к библиотеке govmomi.

На днях компания VMware выпустила небольшое обновление своей платформы виртуализации vSphere 6.7 - вышел апдейт vCenter Server 6.7 Update 1b, а также патч к ESXi 6.7.

Обновление к vCenter не содержит никакого нового функционала, однако закрывает несколько серьезных проблем и багов, которые были обнаружены с момента релиза платформы в октябре прошлого года в компонентах vCenter и vSAN.

Например, как вам вот такой баг:

In the vSphere Client, if you right-click on a folder and select Remove from Inventory from the drop-down menu, the action might delete all virtual machines in that folder from the disk and underlying datastore, and cause data loss.

То есть вместо убирания машины из инвентори в vSphere Client, происходит удаление всех виртуальных машин из этой папки с диска. Так что лучше обновите свой vCenter уже сегодня. Надо еще помнить, что, по-прежнему, не поддерживается прямое обновление vCenter Server 6.5 Update 2d и 2e на этот релиз. Странно, но VMware никак не может это починить.

Кроме этого VMware выпустила важные патчи к ESXi 6.7, которые содержат исправления ошибок и апдейт подсистемы безопасности.

Тут ничего особенно критичного, но все равно лучше обновиться, особенно если вы используете решение NSX-T.

Недавно компания VMware опубликовала очередной набор практических упражнений Feature Walkthroughs по апгрейду VMware vCenter 6.7 с прошлых версий управляющего сервера. Они рассказывают об обновлении с помощью интерфейса командной строки vCenter Server Appliance (vCSA) CLI, а также средствами графического интерфейса мастера установки.

Напомним, что Feature Walkthroughs позволяют администратору пройти в интерфейсе тот или иной рабочий процесс виртуальной инфраструктуры без необходимости развертывания у себя тестовой среды.

1. Апгрейд vCenter через через vCSA CLI.

В рамках демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 администратор может узнать, каким образом выглядит консольное обновление Embedded vCenter на последнюю версию. Вам покажут как создать и редактировать настроечный JSON-файл, а также правильно использовать параметры консольной утилиты vcsa-deploy.exe.

Кстати, обратите внимание, что обновление vSphere 6.5 Update 2d на vSphere 6.7 все еще не поддерживается.

2. Апгрейд через графический инсталлятор VMware vCSA.

С помощью демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 using the GUI вы можете пройти по шагам процесса обновления vCenter на последнюю версию в рамках vCSA Installer и его рабочего процесса Upgrade:

Также советуем почитать наши посты о миграции с vCenter for Windows на виртуальный модуль vCSA:

• Миграция сервера VMware vCenter для Windows на виртуальный модуль vCenter Server Appliance 6.7 Update 1
• Функции VMware vCenter Server Appliance для миграции сервера vCenter под Windows

Как знают администраторы больших инфраструктур VMware, для среды управления vSphere есть компонент Platform Services Controller, который может быть внешним (External PSC) и внедренным (Embedded PSC). Недавно мы писали о том, как провести миграцию на внедренный PSC с внешнего PSC с помощью утилиты vCenter Server Converge Tool.

VMware везде рассказывает об этом неспроста - недавно было заявлено, что в следующей версии VMware vSphere внешний сервис PSC будет отсутствовать в принципе. А в данный момент Embedded PSC является рекомендуемым способом развертывания инфраструктуры vCenter (как и виртуальный модуль vCSA).

Возможность создания внешнего PSC появилась в версии vSphere 6.0, а еще в vSphere 5.1 компания VMware предоставила возможность размещать отдельные компоненты, такие как VMware Update Manager (VUM) или vCenter Server Database (VCDB) на отдельных серверах. Это привело к тому, что средства управления виртуальной инфраструктурой можно было развернуть аж на 6 серверах, что рождало проблемы интеграции, обновления и сложности обслуживания.

Когда VMware предложила модель с внешним PSC инфраструктура свелась всего к двум узлам сервисов vCenter. PSC обслуживает инфраструктуру SSO (Single Sign-On), а также службы лицензирования, тэгов и категорий, глобальных прав доступа и кастомных ролей. Помимо этого PSC отвечает за сертификаты данного SSO-домена.

В то время, как службы PSC принесли гибкость развертывания, они же принесли и сложность обслуживания, так как для них нужно было обеспечивать отдельную от vCenter процедуру отказоустойчивости в инфраструктуре распределенных компонентов vCenter Enhanced Linked Mode (ELM).

Еще в vSphere 6.7 и vSphere 6.5 Update 2 была введена поддержка режима ELM для Embedded PSC, поэтому с внедренным PSC уже не требуется обеспечивать отказоустойчивость дополнительных узлов, балансировку нагрузки, а также их обновление. Теперь можно обеспечивать доступность узлов vCenter посредством технологии vCenter High Availability.

Поэтому уже сейчас можете использовать vCenter Server Converge Tool для миграции внешних PSC на Embedded PSC виртуального модуля vCenter Server Appliance. А возможности развернуть внешние PSC в следующих версиях vSphere уже не будет.

Как многие из вас знают, VMware vCenter для Windows версии 6.7 (на данный момент Update 1) - это последний vCenter, который еще доступен как отдельный продукт для Windows-машины. Следующая версия vCenter будет поставляться только как виртуальный модуль vCenter Server Appliance на базе Photon OS от VMware.

Мы уже писали о некоторых аспектах миграции на vCSA с vCenter for Windows, но в этом посте дадим несколько новых деталей по этому процессу. VMware рекомендует выполнить 2 основных шага миграции с vCenter на vCSA:

• Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
• Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.

Полный обзор процесса миграции показан в видео ниже:

Обратите внимание, что во время миграции вы можете выбрать опцию импорта исторических данных из старой копии vCenter for Windows в созданную новую копию vCSA (это опциональный процесс во время миграции, и можно сделать импорт уже позднее).

Migration Tool делает импорт всех скопированных данных в развернутый виртуальный модуль vCSA (включая параметры идентификации vCenter, такие как FQDN, IP-адрес, UUID, сертификаты, MoRef IDs и прочее). Также происходит миграция и vSphere Distributed Switch (vDS).

Надо отметить, что в процессе миграции не происходит никаких изменений в исходном vCenter, поэтому откат в случае неудачного обновления прост - останавливаете vCSA и продолжаете использовать vCenter Server for Windows.

Помимо всего этого есть утилита vCenter Server Converge Tool (о ней мы писали тут и тут), которая позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее администраторы использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.

Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.

Пройтись по шагам различных вариантов миграции vCenter и его PSC (встроенного или внешнего) можно вот в этих обучающих материалах VMware (там вы все это можете прокликать прямо в интерфейсе):

• Windows External PSC 6.5 Migration to an External PSC 6.7 Appliance
• Windows vCenter Server 6.5 External Migration to VCSA 6.7
• Windows vCenter Server 6.5 Embedded Migration to VCSA 6.7
• Windows External PSC 6.0 Migration to an External PSC 6.5 Appliance
• Windows vCenter Server 6.0 External Migration to VCSA 6.5
• Windows vCenter Server 6.0 Embedded Migration to VCSA 6.5

В целом процесс миграции vCenter выглядит так:

Кстати, надо понимать, что процесс миграции vCenter - это одновременно и его апгрейд. То есть вы можете, например, провести миграцию-апгрейд vCenter Server 6.0 на VCSA версии 6.7.

Ну и помните, что весь самый новый функционал есть только в VMware vCSA, который является рекомендуемым вариантом развертывания по умолчанию. Вам уже давно пора перейти на vCSA, если вы все еще пользуетесь vCenter для Windows.

В догонку к найденным и, вроде бы, поборенным уязвимостям Meltdown и Spectre, в процессорах Intel нашли еще одну потенциальную дыру - L1 Terminal Fault Vulnerability, которая затрагивает современные процессоры (2009-2018 годов выпуска) и гипервизор VMware ESXi (а также и все остальные гипервизоры).

Для начала надо сказать, что на днях стали доступны вот такие патчи для платформы виртуализации VMware vSphere, которые настоятельно рекомендуется установить:

VMware vCenter:

• vCenter Server 6.7 – VC 6.7.0d build 9451876
• vCenter Server 6.5 – VC 6.5 Update 2c – build 9451637
• vCenter Server 6.0 – VC 6.0 Update 3h – build 9451619
• vCenter Server 5.5 – VC 5.5 Update 3j – build 9313450

VMware ESXi:

• ESXi 6.7 – ESXi670-201808401-BG
• ESXi 6.5 – ESXi650-201808401-BG
• ESXi 6.0 – ESXi600-201808401-BG
• ESXi 5.5 – ESXi550-201808401-BG

Суть уязвимости, описанной в CVE-2018-3646 заключается в том, что виртуальная машина, исполняемая на конкретном ядре, может получить доступ к данным других машин, использующих это ядро, или самого гипервизора через L1 Data Cache, который совместно используется машинами, выполняющими команды на данном ядре.

Для такой уязвимости возможны 2 типа векторов атаки:

• Sequential-context - вредоносная машина получает доступ к данным другой ВМ, которая исполнялась на этом ядре ранее и получала доступ к кэшу L1.
• Concurrent-context - вредоносная машина прямо сейчас получает доступ к данным ВМ или гипервизора, которые исполняются планировщиком на этом ядре.

Решение вопроса уровня Sequential-context заключается просто в накатывании патчей, которые не должны приводить к падению производительности (как это было с Meltdown и Spectre). А вот для избавления от риска применения вектора атаки Concurrent-context нужно включить фичу, которая называется ESXi Side-Channel-Aware Scheduler. И вот в этом случае влияние на производительность может уже быть существенным, поэтому нужно либо принять риск Concurrent-context, либо следить за производительностью систем.

Таким образом, процесс обновления инфраструктуры VMware vSphere должен выглядеть так:

• Обновляете сначала серверы vCenter, потом хосты ESXi.
• Смотрите, есть ли на хостах запас по CPU на случай возникновения проблем с производительностью.
• Если запас есть - включаете функцию ESXi Side-Channel-Aware Scheduler и наблюдаете за производительностью систем по CPU.

Детальные инструкции по включению ESXi Side-Channel-Aware Scheduler вы найдете здесь. Действовать нужно по следующей схеме:

Ну и в заключение, вот список процессоров, которые подвержены атакам типа L1 Terminal Fault:

На днях компания VMware выпустила финальную версию своего руководства по обеспечению безопасности виртуальной инфраструктуры vSphere 6.7 Update 1 Security Configuration Guide. Напомним, что ранее мы писали о документе vSphere 6.5 Update 1 SCG, который описывал основные аспекты обеспечения безопасности прошлой версии платформы (оказывается, был и гайд по vSphere 6.7 - он публично не анонсировался, но теперь находится в статусе Deprecated).

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.

Сейчас распределение по этим настройкам выглядит так (50 настроек в vSphere 6.7 U1 против 68 опций в версии vSphere 6.5 U1):

Давайте посмотрим на отличие vSphere 6.7 U1 SCG от прошлых версий руководства:

• Появились настройки категории deprecated - они описывают параметры ESXi или vCenter, которые больше нет необходимости изменять, так как они потеряли актуальность. Все настройки этой категории приведены в отдельном документе, который настоятельно рекомендуется изучить. Если вы их использовали - то лучше перестать это делать, так как это только добавляет дополнительной работы по их обслуживанию.
• Больше нет категории "Risk Profiles". Причина в том, что только настройка "ESXi.enable-strict-lockdown-mode" подпадает под Risk Profile 1, а остальные находятся во 2-й или 3-й категории, поэтому было решено отказаться от этой таксономии. Вместо этого было добавлено больше содержимого в колонку Vulnerability Discussion, где обсуждаются конкретные факторы риска.
• Настройка vNetwork.enable-bpdu-filter переместилась из категории Hardening в Site Specific, так как при нормальных условиях функционирования сети ее менять не требуется (а она также затрагивает конфигурацию аппаратных коммутаторов и гостевой ОС). Да, она защищает от Spanning Tree Loops, но в нормально настроенной сетевой конфигурации менять ее не следует.

В гифке ниже можно посмотреть прогресс Security Configuration Guide с версии vSphere 6.5:

Скачать VMware vSphere 6.7 Update 1 Security Configuration Guide можно по этой ссылке.

Мы уже писали о новых возможностях платформы виртуализации VMware vSphere 6.7 Update 1, которая стала доступна для загрузки совсем недавно. Сегодня мы остановимся на отдельных новых функциях управляющего сервера VMware vCenter Server 6.7 Update 1 и его клиента vSphere Client 6.7 U1 на базе технологии HTML 5, который стал полнофункциональным и заменил ушедший в прошлое Web Client.

Давайте посмотрим, что нового появилось в VMware vCenter Server 6.7 Update 1:

1. Улучшенные возможности поиска.

Теперь при поиске различных объектов можно использовать строковый параметр и различные фильтры (например, тэги, кастомные атрибуты и состояние питания ВМ). Также очень удобная функция - это возможность сохранить результаты поиска:

2. Темная тема vSphere Client.

Об этой функции мы уже упоминали - это один из главных запросов администраторов vSphere, которые любят поуправлять виртуальной инфраструктурой в темноте.

3. Утилита vCenter Server Converge Tool.

Эта новая утилита позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее пользователи использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.

Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.

Утилита vCenter Server Converge Tool работает из командной строки (команда vcsa-converge-cli) и поставляется в комплекте с установщиком vCSA. Ее можно запускать в ОС Windows, macOS и Linux, а конфигурируется она через файл в формате JSON:

Надо понимать, что теперь Embedded PSC - это рекомендуемый способ развертывания инфраструктуры vCenter:

4. Функции Embedded Domain Repoint.

vCenter Server с компонентом embedded PSC с помощью функции Domain Repoint теперь можно перенаправить на другой домен vSphere SSO (это позволяет более гибко распределять и разделять домены SSO в корпоративной инфраструктуре). Ранее это было сделано только для внешних SSO, а теперь доступно и для vCSA.

5. Улучшения vSphere 6.7 Update 1 vCenter High Availability.

Функции vCenter HA были введены еще в vSphere 6.5. Теперь эти возможности были доработаны - вместо рабочих процессов basic и advanced появился единый и простой workflow. Он включает в себя три стадии:

• Создание vSphere SSO credentials для управление сервером vCenter и всей инфраструктурой.
• Настройки ресурсов для пассивного узла и узла Witness, включая вычислительные ресурсы, хранилище и сеть.
• Настройки IP для пассивного узла и узла Witness.

Также в процессе настройки автоматически создается клон активного vCenter для создания пассивного узла и Witness - для этого лишь нужно ввести учетные данные vSphere SSO.

Во время апгрейда автоматически обнаруживаются настройки vCHA, поэтому при обновлении на новую версию не требуется разбивать кластер серверов vCenter. Это учитывает мастер обновления и накатывает апдейт.

6. Интерфейс REST API для VCHA.

Для механизма vCenter High Availability стал доступен API, который позволяет управлять кластером vCenter:

7. Улучшения Content Library.

Теперь OVA-шаблоны можно импортировать из HTTPS-источника или с локального хранилища. Также содержимое OVA-пакетов можно синхронизировать между несколькими серверами vCSA (сами шаблоны синхронизировать пока нельзя). Content Library обрабатывает сертификаты и файлы манифеста, входящие в OVA-пакеты в соответствии с лучшими практиками безопасности.

Content Library также нативно поддерживает формат шаблонов VMTX и ассоциирует с ними операции, такие как развертывание ВМ напрямую из Content Library.

8. Функция vSphere Health.

Это новая функциональность vCenter с большим потенциалом. Она позволяет при включенной функции передачи данных CEIP (customer experience improvement program) обрабатывать данные телеметрии виртуальной инфраструктуры на стороне VMware и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас один Management network, вам могут порекомендовать его задублировать.

9. Улучшения Virtual appliance management interface (VAMI).

В интерфейсе VAMI появилась новая вкладка Firewall, где можно задавать правила сетевого экрана на vCSA (ранее это было доступно только через VAMI API):

Также появилась возможность зайти в VAMI под локальным vSphere SSO аккаунтом, который является членом группы SytemConfiguration.Administrators. Также члены группы Systemonfiguration.BashShellAdministrators могут зайти в шелл VCSA, например, для целей аудита безопасности.

Спустя несколько недель ожидания после анонса обновленной версии платформы виртуализации VMware vSphere 6.7 Update 1, компания VMware сделала ее доступной для загрузки. Скачать продукт, включая ESXi 6.7 Update 1 и vCenter 6.7 Update 1, можно по этой ссылке:

https://my.vmware.com/en/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/6_7

Напомним, что обо всех новых возможностях этого решения мы писали вот тут. Кроме того, в составе vSpher 6.1 Update 1 стал доступен и VMware vSAN 6.7 Update 1, про который мы писали вот тут.

Ну и главная новость этого релиза - это, бесспорно, полнофункциональный vSphere Client на базе HTML5! Мы ждали этого годами, и это сбылось. Вот пост об этом от VMware, там много подробностей, о которых мы скоро тоже расскажем.

Для него, кстати, доступна темная тема (см. последние наши новости о vSphere Client 3.42):

Клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).

Вкратце суммаризуем все новые возможности VMware vSphere 6.7 Update 1:

• Полнофункциональный VMware vSphere Client на базе HTML5
• Утилита vCenter Server Converge Tool для миграции на внедренный (embedded) PSC
• Новая версия vSAN и улучшения HCI (обновления микрокода через Update Manager)
• Улучшения Content Library
• vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA

Отдельно давайте посмотрим, а что нового появилось в VMware vSAN 6.7 Update 1:

• Новый мастер Cluster quickstart
• Обновление драйверов и firmware через Update Manager
• Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания
• Разные представления vROPs для обычных и растянутых кластеров vSAN
• Улучшенные возможности Capacity reporting
• Поддержка TRIM/UNMAP
• Поддержка режима Mixed MTU для растянутых кластеров
• Обновленные средства для сайзинга инфраструктуры
• Улучшенные функции Health Check
• Улучшенная диагностика для персонала поддержки VMware GSS

Обновить VMware vCenter Server Appliance 6.7 на Update 1 можно через интерфейс VAMI (vCenter Appliance Management Interface, он же Appliance Management User Interface или MUI):

Ну и, конечно же, скоро будет много интересных статей про отдельные фичи. Не забывайте наведываться.

Когда мы писали о новых возможностях платформы VMware vSphere 6.5 два года назад, мы упомянули о новой возможности резервного копирования и восстановления сервисов vCenter на уровне файлов. Сегодня мы расскажем о функциональности VMware vCenter File-Based Backup and Restore несколько подробнее.

Этот механизм доступен через интерфейс VMware Appliance Management Interface (VAMI), работа с которым происходит по порту 5480. Бэкапить можно как сам сервер vCSA, так и службы Platform Services Controller (PSC). При этом во время бэкапа не потребуется никаких дополнительных процедур - ни установки агентов, ни "подмораживания" служб vCenter на время работы резервного копирования.

В качестве канала для бэкапа может быть использован один из протоколов: FTP(s), HTTP(s) или SCP. По ним передаются все файлы, составляющие сервисы vCenter, включая файлы базы данных. Во время восстановления vCSA или PSC вам потребуется только монтирование ISO-образа vCSA.

Процесс восстановления подразумевает развертывание нового ISO-образа vCSA с сохранением прошлых параметров идентификации (UUID и прочее). После развертывания образа происходит накат забэкапленных файлов.

В VMware vSphere 6.7 сервисы резервного копирования и восстановления vCenter были существенно улучшены. Во-первых, для этой задачи появился отдельный раздел Backup. Во-вторых, появилась опция запланированного бэкапа, которая очень удобна:

В качестве места назначения резервных копий используется адрес:

Protocol://Server Address: Port/Backup Folder/Subfolder

При этом вам не нужно создавать папки Backup Folder (по умолчанию это "vCenter") и Subfolder (по умолчанию это VCSA FQDN) - они будут созданы автоматически.

В третьих, обратите также внимание на новую опцию Number of backups to retain - она позволит хранить несколько бэкапов. После создания расписания резервного копирования его можно изменять в любой момент:

Обратите внимание, что внизу приведен список выполненных задач и их статусы.

Также в версии vCSA 6.7 появился браузер файлов резервного копирования, поэтому теперь нет необходимости знать все пути к бэкапам. Кстати, обратите внимание на первую букву в названии бэкапа (S - значит scheduled, то есть запланированный, а M - manual, сделанный вручную).

При восстановлении сервера vCSA вам понадобятся данные учетной записи vSphere SSO. Если у вас несколько внешних серверов PSC, то в этом случае не поддерживается восстановление узла PSC при доступности остальных партнеров. Надо вывести этот узел из эксплуатации с помощью команды cmsso-util unregister и развернуть новый узел PSC, синхронизировав его с партнерами. В этом и будет суть восстановления узла PSC.

Также для целей обучения у VMware есть свои Walkthrough, которые очень полезно пройти, чтобы увидеть процесс резервного копирования и восстановления vCenter в деталях:

• vCenter Server Appliance 6.7 File-Based Backup
• vCenter Server Appliance 6.7 File-Based Restore

Информация этой заметки не покажется многим из вас новой, но для некоторых может оказаться полезной. Как вы знаете, управляющий компонент VMware vCenter Server сейчас поставляется в двух изданиях vCenter Server, устанавливаемый на платформе Windows, и vCenter Server Appliance (vCSA), представляющий собой готовую к использованию виртуальную машину с сервисами vCenter.

Напомним, что развертывание vCSA уже является опцией по умолчанию, а vCenter для Windows уже не будет присутствовать в следующих версиях VMware vSphere после 6.7.

На данный момент есть 3 издания VMware vCenter:

1. VMware vCenter Essentials

Это издание vCenter недоступно к отдельному заказу. Оно входит в состав изданий vSphere Essentials и vSphere Essentials Plus, которые допускают управление не более чем тремя хостами ESXi (в каждом не более двух физических CPU). Помимо данного ограничения, vCenter Essentials не имеет поддержки таких функций как (детальнее о них - далее):

• Enhanced Linked Mode (ELM) 
• vCenter Server High Availability (VCHA) 
• vCenter Server File-Based Backup and Restore
• vCenter Server Migration Tool
• vRealize Orchestrator

vCenter Essentials в составе издания Essentials Plus можно проапгрейдить на vCenter Standard в составе пакета vSphere with Operations Management Acceleration Kit для одного из более высших изданий:

2. VMware vCenter Foundation

Это издание vCenter также не содержит в себе пять перечисленных выше фичей, но позволяет управлять не тремя, а уже четырьмя хостами ESXi с любым числом физических процессоров на борту (ранее число хостов было равно трем, но, начиная с vSphere 6.5 Update 1, его увеличили до четырех). Его можно купить отдельно от лицензий на хосты VMware vSphere / ESXi.

Одна лицензия vCenter Foundation также позволяет создать растянутый кластер из двух площадок, на каждой из которых есть по два хоста ESXi (суммарно под управлением vCenter там находится 4 хоста и Witness VM).

3. VMware vCenter Standard

Это, несмотря на название, самое максимальное издание vCenter. Оно не ограничивает никакую функциональность, то есть в нем доступно управление аж до 2000 хостами ESXi. Здесь вам будут доступны возможности объединения нескольких управляющих серверов Enhanced Linked Mode (ELM), но для каждого из серверов vCenter нужна, само собой, отдельная лицензия Standard.

Также вы сможете производить резервное копирование на уровне файлов (File-Based Backup and Restore) и обеспечивать высокую доступность сервисов vCenter (VCHA) - при этом для нее не нужна дополнительная лицензия на резервный vCenter, хватит одной:

Помимо этого, пользователи vCenter Standard могут применять vCenter Server Migration Tool для миграции с сервисов vCenter для Windows на платформу vCSA. Ну и можно использовать vRealize Orchestrator, который очень пригодится для автоматизации операций в больших инфраструктурах.

На днях в Лас-Вегасе началась конференция VMworld 2018 - главное в году событие в сфере виртуализации. Компания VMware уже в первый день представила немало анонсов новых продуктов и решений, но одним из главных стало объявление о выпуске обновления серверной платформы виртуализации VMware vSphere 6.7 Update 1.

На картинке выше приведены 5 основных новых возможностей vSphere 6.7 U1, давайте посмотрим на них поближе:

1. Полнофункциональный VMware vSphere Client на базе HTML5.

Наконец-то свершилось - VMware выпустила полную версию vSphere Client на базе технологии HTML5, которая заменяет собой устаревший vSphere Web Client. Теперь все операции можно будет делать через один удобный и быстрый клиент. Напомним, что VMware очень долго к этому шла, постоянно откладывала релиз полной версии, но в итоге пользователи получат единый инструмент управления виртуальной инфраструктурой.

Теперь клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM). Теперь нет нескольких рабочих процессов, делающих то же самое (раньше были Basic и Advanced), а также улучшились функции работы с Content Library, появился расширенный поиск, упростилась настройка запланированных задач и появились графики top-N (топы по использованию ресурсов).

2. Утилита vCenter Server Converge Tool.

Эта новая утилита позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее пользователи использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.

Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.

Теперь вам не нужны сложные HA-топологии PSC с балансировщиками на разных площадках, серверы vCSA с внедренными PSC на них можно просто соединить между собой.

Утилита vCenter Server Converge Tool работает из командной строки (команда vcsa-converge-cli) и поставляется в комплекте с установщиком vCSA. Ее можно запускать в ОС Windows, macOS и Linux, а конфигурируется она через файл в формате JSON:

Еще одна задача, которая была решена - vCenter Server с компонентом embedded PSC теперь можно перенаправить на другой домен vSphere SSO (это позволяет более гибко распределять и разделять домены SSO в корпоративной инфраструктуре). Ранее это было сделано только для внешних SSO, а теперь доступно и для vCSA.

3. Новая версия vSAN и улучшения HCI.

В новой версии vSAN появилась функция Cluster Quickstart, которая позволяет инициализировать кластер, добавить в него хосты и накатить идентичную конфигурацию на них. Она включает в себя настройку механизмов HA и DRS, Enhanced vMotion Compatibility (EVC), датасторов vSAN и сетевого взаимодействия, включая Virtual Distributed Switch (VDS).

Этот воркфлоу можно использовать и для добавления новых хост-серверов ESXi в кластер, а также для его валидации (проверка корректности и идентичности настроек на всех хостах с оповещением о найденных несоответствиях).

Также появилась интеграция микрокода контроллера ввода-вывода с vSphere Update Manager (VUM), который использует утилиту обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее (можно использовать как дефолтный, так и свой репозиторий):

4. Улучшения Content Library.

Теперь OVA-шаблоны можно импортировать из HTTPS-источника или с локального хранилища. Также содержимое OVA-пакетов можно синхронизировать между несколькими серверами vCSA (сами шаблоны синхронизировать пока нельзя). Content Library обрабатывает сертификаты и файлы манифеста, входящие в OVA-пакеты в соответствии с лучшими практиками безопасности.

Content Library также нативно поддерживает формат шаблонов VMTX и ассоциирует с ними операции, такие как развертывание ВМ напрямую из Content Library.

5. vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA.

Теперь технология NVIDIA Quadro vDWS (ранее она называлась GRID) для vGPU поддерживается со стороны vSphere 6.7 Update 1. Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS. Это позволит обновлять хосты с тяжелыми операциями (например, десктопы с CAD-приложениями) без прерывания работы пользователей.

Также VMware объявила о поддержке карточек Intel Programmable Acceleration Card с технологией Intel Arria 10 GX FPGA. Эта технология позволяет получить прямой доступ к оборудованию с помощью механизма VMware DirectPath I/O через Intel Acceleration Stack для процессоров Intel Xeon CPU с FPGA.

Также в рамках VMworld 2018 было анонсировано новое издание - vSphere Platinum, которое предоставляет расширенные функции обеспечения безопасности для корпоративной инфраструктуры. О нем мы расскажем в следующей статье.

О дате доступности для загрузки обновления VMware vSphere 6.7 Update 1 пока не сообщается.

На днях компания VMware выпустила несколько минорных обновлений серверной продуктовой линейки. Давайте посмотрим, что нового стало доступно для загрузки:

1. Обновление VMware Horizon 7.5.1

В этом обновлении не появилось ничего нового, за исключением исправления безопасности CVE-2018-6971. Эта уязвимость заключается в том, что в процессе установки Horizon в файл vmmsi.log записывалась информация об учетных записях, которую могли считать привилегированные пользователи. Более подробно об этом рассказано тут.

Более подробно о самом обновлении можно прочитать в Release notes. Скачать VMware Horizon 7.5.1 можно по этой ссылке.

Здесь было сделано несколько улучшений служб управления:

• Pivotal tc Server заменен на сервер Tomcat версий 8.5.24 и 8.5.23.
• Кастомизация гостевых ОС Windows и Linux на vCenter Server поддерживает самые актуальные временные зоны.
• Поддержка TLS версии 1.2 для защищенного соединения с Microsoft SQL Server.
• Поддержка баз данных Microsoft SQL Server 2014 Service Pack 2, SQL Server 2016, SQL 2016 Service Pack 1 и SQL Server 2012 Service Pack 4.

Более подробно об обновлении можно прочитать в Release notes. Скачать VMware vCenter Server 6.0 Update 3g можно по этой ссылке.

3. Обновление VMware vSphere Integrated Containers 1.4.2

В этом обновлении только пофикшена проблема интеграции vSphere Integrated Containers Registry с компонентом сканирования на уязвимости Clair. Более подробно это улучшение описано вот тут.

Более подробно об обновлении можно прочитать в Release notes. Скачать vSphere Integrated Containers 1.4.2 можно по этой ссылке.

4. Обновление VMware vCenter Server 6.7.0c

Это обновление содержит в себе только исправления ошибок, которые описаны в разделе Resolved Issues документа Release notes. Скачать vCenter Server 6.7.0c можно по этой ссылке.

На сайте проекта VMware Labs обновилась полезная утилита Cross vCenter Workload Migration, которая предназначена для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Напомним, что о первой ее версии мы писали в конце прошлого года вот тут.

По отзывам пользователей, утилита Cross vCenter Workload Migration часто пригождается, когда требуется массовая миграция сотен и тысяч виртуальных машин между распределенными датацентрами.

Во-первых, в новой версии добавилась возможность указывать целевой пул ресурсов и папку (VM Folder), куда требуется переместить выбранные виртуальные машины:

Это позволяет реализовывать массовые миграции с точки зрения организационной структуры (папки) и с точки зрения использования ресурсов (пулы).

Во-вторых, появилась поддержка VMware Cloud on AWS (VMC). Раньше Cross vCenter vMotion Utility не поддерживала специфическую иерархию ресурсов и прав доступа AWS, но теперь все работает отлично. Вот пример миграции ВМ в облачный датацентр из онпремизного:

Также обратим внимание, что за прошедшие несколько месяцев утилита приобрела следующую функциональность:

• Увеличилось число одновременных миграций с 10 до 100.
• Появилась возможность выбрать целевой хост ESXi для миграции.
• Поддерживается миграция ВМ с общими хранилищами, а также еще и функции клонирования в дополнение к миграции.
• Улучшилось отображение свойств и ресурсов ВМ, а также интерфейс REST API.

Скачать Cross vCenter Workload Migration Utility можно по этой ссылке. А вот, кстати, обзорное видео об этом средстве:

Некоторые из вас знают, что у VMware есть лицензия VMware vCenter Server Foundation, которая позволяет подцепить к серверу vCenter до 4 хостов VMware ESXi. Такая лицензия стоит дешевле обычного vCenter и позволяет построить растянутый кластер (stretched cluster) из четырех хостов ESXi, например, на уровне основного датацентра и филиала (это обеспечивает отказоустойчивость HA на уровне каждой площадки):

Проблема здесь возникает тогда, когда вы пытаетесь добавить виртуальный модуль Witness Virtual Appliance на один из хостов. Так как Witness VM - это виртуальный хост ESXi, то несмотря на то, что он не исполняет виртуальных машин, сервер vCenter считает его пятым хостом и отказывается добавлять его.

Решение проблемы описано в Release Notes для VMware vCenter Server 6.5 Update 2 (см. пункт в самом низу) - нужно просто с самого начала импортировать Witness VM в inventory сервера vCenter (при добавлении первым он не будет съедать лицензию), после чего уже добавить 4 хоста ESXi, которые в этом случае подцепятся без проблем.

Многие из вас знают, что на днях компания VMware выпустила обновление виртуального модуля для управления виртуальной инфраструктурой - VMware vCenter Server Appliance 6.7a. В основном, в этом обновлении были исправлены ошибки, связанные с апгрейдом на новую версию vSphere 6.7 с прошлых 6.5 и 6.0. Также иногда зависал vSphere Web Client при логине, и эта проблема была тоже исправлена.

Но самое интересное, что и в новой версии vCSA 6.7a тоже есть небольшая проблема апгрейда уже с версии 6.7:) Стандартно процедура обновления виртуального модуля vCenter выглядит так:

1. Через интерфейс CLI.

Добавляем образ VMware-vCenter-Server-Appliance-6.7.0.11000-8546234-patch-FP.iso к серверу vCenter Server Appliance как CD/DVD drive.

Идем на vCSA по SSH как root и выполняем команды:

• Для стейджинга ISO: software-packages stage –iso
• Для просмотра контента на стейджинге: software-packages list –staged
• Для установки rpm-пакетов со стейджинга: software-packages install –staged

2. Через интерфейс VAMI.

• Добавляем образ VMware-vCenter-Server-Appliance-6.7.0.11000-8546234-patch-FP.iso к серверу vCenter Server Appliance как CD/DVD drive.
• Логинимся в интерфейс VAMI по адресу https://fqdn-of-vcenter:5480
• Нажимаем Update и в правом верхнем углу выбираем Check Updates -> Check CD Rom.
• Нажимаем Update, затем Stage и Install.

Также это обновление можно сделать по URL новой версии, которая дефолтно должна находиться в рамках процедуры описанной выше, только без присоединения ISO-образа к vCSA. Но сейчас в этом апдейте какие-то проблемы с этим, поэтому когда нажмете кнопку Update в VAMI, то затем надо нажать Settings и добавить туда следующий URL:

https://vapp-updates.vmware.com/vai-catalog/valm/vmw/8d167796-34d5-4899-be0a-6daade4005a3/6.7.0.10000.latest/

Интересно также, что апгрейд с недавно вышедшей VMware vSphere 6.5 Update 2 на VMware vSphere 6.7 не поддерживается. Надо ждать очередного обновления:)